home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv4.zip / V4N22M.TXT < prev    next >
Text File  |  1994-01-23  |  11KB  |  261 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Musician's Digest       Sat, 22 Jan 94  3:13         Volume 4: Issue  22  
  5.  
  6. Today's Topics:
  7.                   Clicks & Pops as DRAM fills up...
  8.                       Cn/9n-event works like...
  9.                      Dropped MIDI program changes
  10.                        Dropped program changes?
  11.                      GUS Musician's Digest V4 #21
  12.                 Power Chords Pro self contained record
  13.                               XMID specs
  14.  
  15. Standard Info:
  16.     - Meta-info about the GUS can be found at the end of the Digest.
  17.     - Before you ask a question, please READ THE FAQ.
  18.  
  19. ----------------------------------------------------------------------
  20.  
  21. Date: Fri, 21 Jan 94 9:10:47 CST
  22. From: umcoyne0@CC.UManitoba.CA
  23. Subject: Clicks & Pops as DRAM fills up...
  24.  
  25. To the chap who mentioned clicks and pops occurring as the patches filled
  26. up the higher portions of GUS memory, it sounds a lot like you have faulty
  27. DRAMs.  Try testing banks 3 and 4 (you can skip banks 1 & 2, if there
  28. aren't any pops in those banks).  It certainly sounds like a DRAM problem,
  29. because you mentioned pops and clicks in percussion instruments; when a
  30. song is loaded, or when MegaEm fills up the memory, melodic instruments
  31. are loaded first and percussion is loaded _last_.  This supports my guess
  32. that your higher RAM is bad/faulty.
  33.  
  34.  
  35. Michael
  36.  
  37. ------------------------------
  38.  
  39. Date: Fri, 21 Jan 94 9:00:10 CST
  40. From: chuth@lonestar.utsa.edu (Cornel H. Huth)
  41. Subject: Cn/9n-event works like...
  42.  
  43. DE said:
  44. >that a few midi files where a single track with the prg changes to
  45. >switch to new instruments, to add interest to a solo, was failing to
  46. >change voices.  After discovering that the prg changes had the same
  47. >midi time stamp as a midi note on, I tried changing the midi time
  48. >stamp on the prg change to precede the first note on of the melody,
  49. >and voila, the prg change was now being seen.  It appears that in
  50. >Forte's effort to guarantee that notes are not dropped, as caused
  51. >there drivers to miss prg changes if they occur with the same time
  52. >stamp as a note on.
  53.  
  54. Then they are going out of their way to do that (heh).
  55.  
  56. If two events are to occur at the same time then they occur in track
  57. order. In other words, if the Cn event is seen in the MIDI stream
  58. before the 9n, then the Cn event executes first. This only if these
  59. events occur on the same track (which they do, of course). For the
  60. noteOn event to take place first would indicate that the arrangment
  61. is being modified after the fact:
  62.  
  63.     I think (only) that the Gravis Windows code reads a MIDI file
  64.     and enters all events, etc., into a linked list. It's possible
  65.     that the list is being sorted by timestamp & event order (event
  66.     order being the culprit). If this were so (don't know if it is)
  67.     then the 9n event (noteOn) will occur before Cn (program change).
  68.     But, like I said, they would have to go out their way to do this.
  69.     And since it makes no sense to do this, I doubt this is happening.
  70.     Only Gravis/Forte know for sure.
  71.  
  72.  
  73. Which reminds me, is there any possibility of getting the Forte tech
  74. support folks to make the corrections to the written documentation
  75. of the 2.10 SDK? Specifically, the missing AM/FM tables. There was mention
  76. of this happening two or three weeks ago in the SDK digest.
  77. --
  78. chh
  79.  Internet: chuth@lonestar.utsa.edu  or  cornel.huth@lchance.sat.tx.us
  80.   Fidonet: 1:387/800.8
  81.       BBS: The 40th Floor;V32b@1(210)684-8065;M-F:5pm-9am,WE:1p-9a CT
  82.  
  83. ------------------------------
  84.  
  85. Date: Fri, 21 Jan 1994 11:00:16 GMT
  86. From: Clarke Brunt <CLARKE@lsl.co.uk>
  87. Subject: Re: Dropped MIDI program changes
  88.  
  89. >... new drivers with PatchMaker Lite miss program changes with same
  90. > time stamp as note on events...
  91.  
  92. Time stamps (in particular, delta times from the previous event) only
  93. have physical existence in MIDI files stored on disk. They are not
  94. sent over MIDI cables, or sent to GUS MIDI drivers. It is up to the
  95. sequencing software to read the delta times and then send the
  96. events at the correct time. I think that we can assume that the
  97. application software is not forgetting to send them, so if they
  98. are missed, it can only be that the drivers miss events arriving
  99. too closely together. Perhaps the program change takes a while to
  100. execute, during which notes are missed.
  101.  
  102. As regards precedence, I don't know the answer. Events at the
  103. same time would be stored in the MIDI file sequentially with zero
  104. delta times. The sequencer would send them quickly one after
  105. another - the order would be up to it - perhaps the order that
  106. they were in the file. But if you get a program change and a note
  107. on at the same time, is the note supposed to play with the old or
  108. new program? I suppose it would depend on which was sent first. Perhaps
  109. to be on the safe side, program changes should not coincide exactly with
  110. note on events.
  111.  
  112. ------------------------------
  113.  
  114. Date: Fri, 21 Jan 1994 21:01:18 -0500 (EST)
  115. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  116. Subject: Dropped program changes?
  117.  
  118. > Date: Thu, 20 Jan 94 8:52:52 CST
  119. > From: Don Eller <don.eller@inst.medtronic.com>
  120. > Subject: newest windows drivers drop midi prg changes
  121. > 
  122. > Has anyone else noticed that the new drivers that came with pmaker
  123. > lite, work quite a bit differently than the old drivers with regard to
  124. > prg change midi messages?  I discovered this while trying to re-record
  125. > some midi files that I'd recorded earlier, because in general
  126. > everything sounds so much better now.  Apparently I was dropping more
  127. > notes than I realized with the old drivers.  Unfortunately I found
  128. > that a few midi files where a single track with the prg changes to
  129. > switch to new instruments, to add interest to a solo, was failing to
  130. > change voices.  After discovering that the prg changes had the same
  131. > midi time stamp as a midi note on, I tried changing the midi time
  132. > stamp on the prg change to precede the first note on of the melody,
  133. > and voila, the prg change was now being seen.  It appears that in
  134. > Forte's effort to guarantee that notes are not dropped, as caused
  135. > there drivers to miss prg changes if they occur with the same time
  136. > stamp as a note on.
  137.  
  138. The new drivers aren't dropping Program Changes for me, but they
  139. are "dropping" notes that occur simultaneously with program
  140. changes.  For example, in the following event list
  141.  
  142.      Time     Event     
  143.      0:000    Pgm Chg 1 17
  144.      1:000    Note On 1 C3 127 5:000
  145.      1:000    Pgm Chg 1 1
  146.      1:000    Note On 1 C6 127 1:000
  147.  
  148. the C3 note is not heard while the C6 note _is_ heard.  The reason?
  149. A program change on a channel shuts off all notes on that channel,
  150. at least with the GUS Windows drivers (can anybody check to see if
  151. a Roland does the same?).  So, at time 1:000 Note C3 is turned on
  152. (with a percussive organ patch), but is then immediately turned off
  153. once the driver processes the subsequent Program Change event.
  154. This can be a problem if a lot of MIDs have this type of sequence,
  155. but since placing a Program Change on the same time stamp as Note On's
  156. is poor practice, I don't think many do.  After the Program Change,
  157. Note C6 is turned on (with a brite piano patch) and isn't shut off
  158. until the end of its natural duration at time 2:000.
  159.  
  160. Note that events are processed in order even if they share the same
  161. time stamp.
  162.  
  163. Phat.
  164.  
  165. ------------------------------
  166.  
  167. Date: Fri, 21 Jan 94 12:16:23 GMT
  168. From: james@maths.exeter.ac.uk
  169. Subject: Re: GUS Musician's Digest V4 #21
  170.  
  171. >From: fergusos@jeff-lab.QueensU.CA (Ferguson Stephen)
  172. >Question 1: where can I find the FAQ so I can avoid asking any FAQ's in the
  173. >future.
  174.  
  175. ftp 128.100.160.36 /pub/pc/ultrasound/submit/gus-midi.faq
  176. or any of the sites mentioned at the end of the digest in the submit directory
  177.  
  178. >From: Andrew Struthers McCallum <andrewm@io.org>
  179. >Subject: Nice lasting, really basy kickdrum sample.
  180. >
  181. >    You know those cars that drive by, and have Rap music playing 
  182. >really loud, and all you can hear from a distance is the really, really low
  183. >kickdrum that seems to hit and then slowly dissapate?  I need a kickdrum like
  184. >that in some raw sample format.  (not a .PAT file)  If anyone has a nice one
  185. >in 8 or 16-bit format, please mail it to me!  Also, if anyone has any nice
  186. >hihat's for hihat rhytms in techno/trance type songs, email them too. 
  187. >Thanks!  (maybe we can trade samples, too)
  188.  
  189. You probably mean an 808 drum sample.  Get Francois Dion's excellent 808 .pat
  190. files and remove the raw data with patch.exe ( o command )
  191. If that isnt enough total baaase for you then try the 909 ones, which are more
  192. hardcore sounding.
  193. These files also have groovy hi hats in them.
  194.  
  195. -- 
  196. James Andrews, Computer Development Officer, Exeter University Maths Dept
  197.  
  198. ------------------------------
  199.  
  200. Date: 21 Jan 94 10:41:16 EST
  201. From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
  202. Subject: Power Chords Pro self contained record
  203.  
  204. Shawn
  205.  
  206. > No I don't. String bending is recordable in Power Chords Pro to any part type.
  207. > There still is no graphical editor for this though. 
  208.  
  209. > Recordable, as in you can manipulate something with the mouse while it is
  210. > playing, or recordable as in you need an external MIDI device?  I'd like to
  211. > see the software/GUS package be as self-contained, yet expandable, as
  212. > possible, naturally.
  213.  
  214. Any sounds you make with the mouse on either of the on-screen instruments in
  215. Power Chords Pro, including bending strings, whizzing up and down the
  216. fretboard, and right mouse clicking on chords in the palette, etc. can be
  217. recorded into the Rhythm Editor, into any part type, including drums. No
  218. external MIDI device needed.
  219.  
  220. Eric
  221.  
  222. ------------------------------
  223.  
  224. Date: Fri, 21 Jan 1994 13:27:16 -0500
  225. From: jgamache@AIX1.si.usherb.ca (Jerry Gamache)
  226. Subject: XMID specs
  227.  
  228. Sorry for the crossposting, my interest is music in a game context. I
  229. am trying to make an initialisation file for ultramid that will
  230. preload all the patches specific for a game. I have all the XMID of
  231. that game and I need a way to know which patches are used.
  232.  
  233. This is my second attempt on this subject, I kept it short.
  234.  
  235.                 Any help will be welcome
  236.  
  237.                     Jerry
  238.  
  239. ------------------------------
  240.  
  241. End of GUS Musician's Digest V4 #22
  242. ***********************************
  243.  
  244. To post to tomorrow's digest:                        <gus-music@dsd.es.com>
  245. To (un)subscribe or get help:                <gus-music-request@dsd.es.com>
  246. To contact a human (last resort):              <gus-music-owner@dsd.es.com>
  247.  
  248. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  249.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  250.                      archive.orst.edu                    /pub/packages/gravis
  251.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  252.                      nctuccca.edu.tw                           /PC/ultrasound
  253. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  254.  
  255. Hints:
  256.       - Get the FAQ from the FTP sites or the request server.
  257.       - Mail to <gus-music-request@dsd.es.com> for info about other
  258.     GUS related mailing lists (general use, programmers, etc.).
  259.  
  260.  
  261.